1. Field of Invention
The present invention relates in general to the digital data processing field and, in particular, to debugger programs. More particularly, the present invention relates to a mechanism for implementing enhanced graphical user interface functions in a graphical debugger for debugging programs with templates.
2. Background Art
In the latter half of the twentieth century, there began a phenomenon known as the information revolution. While the information revolution is a historical development broader in scope than any one event or machine, no single device has come to represent the information revolution more than the digital electronic computer. The development of computer systems has surely been a revolution. Each year, computer systems grow faster, store more data, and provide more applications to their users.
A modern computer system typically comprises at least one central processing unit (CPU) and supporting hardware, such as communications buses and memory, necessary to store, retrieve and transfer information. It also includes hardware necessary to communicate with the outside world, such as input/output controllers or storage controllers, and devices attached thereto such as keyboards, monitors, tape drives, disk drives, communication lines coupled to a network, etc. The CPU or CPUs are the heart of the system. They execute the instructions which comprise a computer program and direct the operation of the other system components.
The overall speed of a computer system is typically improved by increasing parallelism, and specifically, by employing multiple CPUs (also referred to as processors). The modest cost of individual processors packaged on integrated circuit chips has made multiprocessor systems practical, although such multiple processors add more layers of complexity to a system.
From the standpoint of the computer's hardware, most systems operate in fundamentally the same manner. Processors are capable of performing very simple operations, such as arithmetic, logical comparisons, and movement of data from one location to another. But each operation is performed very quickly. Sophisticated software at multiple levels directs a computer to perform massive numbers of these simple operations, enabling the computer to perform complex tasks. What is perceived by the user as a new or improved capability of a computer system is made possible by performing essentially the same set of very simple operations, using software having enhanced function, along with faster hardware.
A programmer develops a software program by producing and entering source code into files using a text editor program. The computer then creates an executable program by translating the source code into machine code. The machine code is the rudimentary instructions understood by the computer. Illustratively, the foregoing software development process is accomplished by running a series of programs. These programs include a compiler for translating the source code into machine code and a linker to link the machine code together to form a program.
An important aspect of the design and development of a computer program is a process known as “debugging”. Debugging involves testing and evaluating the software to find and correct any errors and improper logic operations. Typically, a programmer uses another computer program commonly known as a debugger to debug a program under development. An effective debugger program is necessary for rapid and efficient development of software and typically provides functions including breakpoints, run-to-cursor, step into, step over, and the like.
A conventional debugging system comprises a combination of computer hardware and debugger software that executes a user's program in a controlled manner. Debugging aids a user in identifying and correcting mistakes in an authored program by allowing the program to be executed in small segments. This approach is enabled primarily by two operations: step functions and breakpoints.
A “step” function permits a computer programmer to process instructions (also known as “statements”) in a computer program one-by-one, and see the results upon completion of each instruction. While the step operation provides the programmer with a large amount of information about a program during its execution, stepping through hundreds or thousands of program instructions can be extremely tedious and time consuming, and may require a programmer to step through many program instructions that are known to be error-free before a set of instructions to be analyzed are executed.
To address this difficulty, conventional debuggers utilize a breakpoint operation, which permits a computer programmer to identify, with a “breakpoint”, a precise instruction for which it is desired to halt execution of a computer program during execution. As a result, when a computer program is executed by a debugger, the program executes in a normal fashion until a breakpoint is reached, and then stops execution and displays the results of the computer program to the programmer for analysis.
Some conventional debuggers support non-conditional breakpoints where the execution of the program is always halted upon reaching the breakpoint. Other conventional debuggers support conditional breakpoints that halt the execution of a program only when a predetermined value, i.e., a condition, is obtained when the breakpoint is encountered.
Breakpoints that are set within a scope typically share common attributes. Thus, if one breakpoint is encountered, the rest of the breakpoints are also encountered. While debugging code within the scope, a user frequently executes an operation, such as a disable operation or an enable operation, on the breakpoints within the scope. If the user desires to execute the same operation on all the breakpoints within the scope, the user would have to execute the same operation on each individual breakpoint within the scope. Individually executing the same operation on each breakpoint within the same scope can be tedious and cumbersome, particularly if the number of breakpoints within the scope is significant.
In order to address this difficulty, it is known to provide conventional debugging systems with a mechanism for simultaneously executing the same operation on the breakpoints within the same scope. For example, U.S. Pat. No. 7,178,135, entitled “SCOPE-BASED BREAKPOINT SELECTION AND OPERATION”, which issued on Feb. 13, 2007 to Bates et al. and is assigned to International Business Machines Corporation, discloses a mechanism for executing the same operation, such as an enabling operation, a disabling operation, or a removing operation, on all the breakpoints within a selected scope. In accordance with that patent's disclosure, breakpoints are indicated as being set on a user interface screen by black arrows proximate lines on one or more panels, such as a breakpoint panel or a source code panel. In the disable operation, all of the breakpoints within a selected scope are disabled and the black arrows proximate each position at which the breakpoint is set are changed to white arrows. In the remove operation, all of the breakpoints within a selected scope are removed from the selected scope and the black arrows proximate each position at which the breakpoint is set are removed.
It is advantageous in the development of software programs to use type parameterization, more commonly referred to as “templates”. For example, C++ templates allow a programmer to implement generic constructs (e.g., vectors, stacks, lists, queues, etc.) that can be used with any arbitrary type. Accordingly, C++ templates advantageously provide a way to re-use source code.
C++ templates offer an interesting challenge to debuggers. With a C++ template, the source code for a single template method may expand into many different methods. The user may intend to set a breakpoint in all the template expansions or just a particular expansion of the template.
In a conventional debugger, when debugging a program with templates, setting a breakpoint using a source code view typically results in a breakpoint being set on all template expansions. Thus, execution of the program will halt whenever that line of source code is encountered. The problem is that, for templates, setting a breakpoint using a source code view often leads to an excessive amount of debug stops, and at each of these debug stops the user must attempt to determine the expansion of the template in which the program is stopped. Typically, the user is not interested in most of the debug stops and, hence, a good deal of the user's time may be wasted.
Also in a conventional debugger, a user may set a breakpoint in a single template expansion using a statement view or an assembly view. The problem is that setting a breakpoint in a single template expansion using a statement view or an assembly view is not easily accomplished. The statement view typically contains procedure names and statement numbers, not source code. Hence, the user must try to locate the procedure(s) and statement(s) that are associated with the correct template expansion. The user may find this confusing and time consuming. The assembly view typically contains assembly code, and the user must try to locate the assembly code associated with the correct template expansion. Again, the user may find this confusing and time consuming.
Therefore, a need exists for an improved debugger having a mechanism when debugging programs with templates to provide enhanced template debug.